Among network protocols is a protocol known as remote program load (RPL) protocol. RPL protocol, originally developed by IBM, allows workstations, such as Heathcliff workstations, to connect to a network and download an operating system from a remote server for configuration on the network. The workstation typically employs a boot ROM on a network adapter card that stores the necessary RPL protocol information, thus allowing the workstation to operate with the network. Thus, the RPL protocol facilitates the use of less expensive workstations on the network.
Although originally developed by IBM, various implementations of the RPL protocol have been developed by other companies for use with their network software, including Novell and Microsoft, two major network system software companies. The variations among these implementations create difficulties, since the workstations cannot blindly attach to a network, but must first identify existence of an appropriate server type on the network to correspond with the implementation addressed by the boot ROM in the workstation.
In prior network configurations, typically only one server of a particular type was available. As networks developed, more than one server existed on the network, but typically only one of each server type appeared on a single network. A block diagram example of such a network is illustrated in FIG. 1. A client workstation 10, such as a Heathcliff workstation, on a network having a plurality of servers, including a Novell server 12, an IBM server 14, and a Microsoft server 16, typically boots to a first available server of an appropriate type for connecting to the network and performing the remote program load. It should be appreciated that server type as used herein refers to the type of system and network operating software and corresponding RPL protocol in use by the server.
Typically, identification and selection begins when a client 10 sends a FIND frame to the network. In response to the FIND frame, the servers 12, 14, 16 each return a FOUND frame. From the FOUND frame, an example of which is shown in FIG. 2, a determination as to the type of server sending the FOUND frame is performed. The example of a FOUND frame in FIG. 2 includes a six byte field of destination address (the client's address), a six byte field of source address (the server's address), a two byte field identifying the packet type, and the data portion of the frame. Once the FOUND frame is received by the client, selection occurs to allow the workstation to boot to the first responding server of a needed type. Conventionally, the FOUND frame from a Novell server has a distinctive `signature` in the data portion of the FOUND frame at an offset from the packet type field of the frame. Thus, if the `signature` is not present, the server type is not Novell. A determination of whether the frame is IBM or Microsoft is suitably performed by comparing the data in the destination address field with the data in the data portion at some offset. An IBM server typically reverses the destination address, while the Microsoft server reproduces the destination address.
With the ability to connect to a network using such techniques, there was usually no need to identify which particular server was being selected for booting. Problems develop, however, in the continued use of these techniques with ever-growing network sizes. Currently, networks tend to have multiple servers of each particular type on a network. Merely booting from a first responding server of a particular type is not guaranteed to allow the workstation access to the network, since the server may not be configured for use with that particular client.
A need exists for a method and system for remote booting to a network with multiple servers of multiple types to allow identification and selection of any one of the multiple servers on the network by a client using a boot ROM.